\chapter{Design Web Service}


\section{Overview}


In this part of our documentation we focus on the web service architecture which represent the online backend of our mobile application. 

We will focus only on the development aspects that directly influenced the mobile design and we will also analyse how the mobile client interacts with the service itself.

The pattern we follow in the building such device procedure was a standard  in web development:
Model View Controller. This patter exploit the intrinsic attitude of a web service to be accessed in by different contexts in very different ways as we web interface and the mobile one we have already describe show.

What MVC stands is the tier separation in the architecture, in particular we split our service in tree main tiers in order to decouple each task in its lifecycle. The two that are relevant from the mobile context are the business tier and the web tier (we omit consideration about the web client interface because our mobile client is the only way we want the user face our system in a mobile context, event if the responsive web design make the navigation possibile also in browser).

After this analysis we present the design choices behind our mobile development, considering the implementation presented above as a model that should be reported also in a mobile context to continue the architectural style we have tested and designed on the we, we the appropriate changes that concern a mobile development environment.


\section{Business Tier}

It is the tier that encapsulate the application logic and interaction with the Database.
Two sub-tiers can be highlighted by focusing on functionality and modelling the application workflow.

\textbf{The Database Interaction} is the first one. We exploit simple DAO Pattern to interact with the datastore service bellow our system. The DAO, called TBOfyService, exposes statically  the main generics methods we need, without take count of the model design.

\textbf{Resource Encapsulation} is the second one, and coconut our model design. Since our ER model is quite complex and can easily change in times (both in terms of entity number and in entity form), we decide to manage them stand alone by spitting the model interaction vertically. 
For each resource in our system a static resource manager is available. This way of thinking makes more simple to understand which part of the application are involved in a particular action and make the code more secure and maintainable by restricting error throws.

Each resource manager offer standard static interaction methods like create(), get(), getCollection(), delete(), but at this level we take also care about specific resource behaviour. In this way we can define such method  in a very simple format reducing the overhead of different variant of simple database interaction in the DAO.

Each level of the application handle the possible errors and then forward only the necessary information to the deeper levels. Security is always a problem in online development and, a we can control much more information hiding with a layered architecture.


\subsection{Technology Choices}

All of our design choices start from the fact that we build our web service over the Google App Engine PaaS. The technologies that this platform offers are a Non-Relation database with a POJO representation of data. Low level API to interact with this kind of database are quite complex because of they miss simple requirements as multi entity transaction or model updating. For this reason we decided to do not interact directly with the database but to uses a Framework: Objectify.

What Objectify offers is a collection of facilities to describe the model behaviour through Java Annotation. In particular we used a lot in our model design the concept of Parent relationship. It can be described as a work around to the missing of join action in non relational databases. Since the datastore perform entity storing like a single tuple <Key, Value>; with the parent relationship each entity with a specific parent is stored near it with a derived Key that make easier the retrieval starting from the parent.

The rules of this concept are simple: an entity can have only one parent and the relation can be se in a hierarchical way. The second aspect make our model sortable and simplify the resource identification that we expose in the next section.

\section{Web Tier}

With web tier we identify the exposed part of our web application.
REST paradigm for web API was the one which inspired our design so decided to propagate the resource centred view also in the Business tier as we describe in the previous section. 
At this point was quite trivial to extend and expose the lower level architecture to this tier by simple adding some standard requirements that concerns API design:
Security
Access Decoupling
Multi-Platform availability



\subsection{Technology Choices}



\subsubsection{Model Translaction}

Observing our model with a hierarchical structure the mains resource which come out was the User at the root of our system and the Question the only Leaf that has a meaning independently of the action context where can be observed.

After this analysis we has decided to represent these main resources also in the reduced data model of our mobile application; other entities in that model refers to particular requirements in the application behaviour:

The \textit{User} is not necessary in the mobile context since the application is a single user access and it represents itself a user. 

The \textit{Question} coupled with the Answer became the central entity in our reduced model.
Test is present because of internet connection reliability, is important for the system to be quite independent from the presence of the internet connection to do not penalise the user experience in the main task of our system: Test Performing.

More on the \textit{Answer} presence, for the same reasons of the Test, it make possible to perform locally task like test correction, without necessarily interact with the web service.

\subsubsection{Async Access Servlet}
